Some computing environments are made up of groups of processors (e.g., arrays, racks, towers, clusters, hyper-cubes, large groups of servers, etc.), and sometimes the number of nodes (e.g., servers, multi-core processors, etc.) that are used by enterprises and others entities can become large (e.g., hundreds of servers, thousands, etc.). In many cases an entire installation might need to be reconfigured to meet the computing needs of the enterprise or other entity. For example, an installation of 256 processors might need to be configured with a Microsoft operating system for a first enterprise, and then all 256 processors might need to be reconfigured to run a Linux operating system for a different, second enterprise.
Often, each individual processor instance needs to boot from an ISO image that has been customized for each respective individual processor. For example, an ISO image might comprise several hundred megabytes that contains the operating system (e.g., Microsoft OS or Linux OS, etc.), plus a few megabytes that comprise patches (security patches, etc.), plus a few megabytes that comprise images of virtual machines that run on top of the hypervisor, etc. In some cluster installations, the total number of unique ISO configurations can approach or equal the total number of processor instances in the cluster.
A further processing element can serve as an orchestrator for configuring/reconfiguring the group of processors. The orchestrator reads configuration data (e.g., a list of nodes and respective configuration specifications) and manages the imaging and boot-up process for each processor in the cluster. In situations where there are a large number of ISO images that have been customized for each respective individual processor, the images are assembled and stored, and the orchestrator processes the imaging and boot-up process for as many as can be concurrently imaged, stored and booted. In many cases, the ISO images that have been customized for each respective individual processor can be imaged to the recipient processor (e.g., over an intelligent platform management interface (IPMI) or network file system (NFS)), and then deleted when the processor has been successfully imaged.
Unfortunately, even for a relatively small group of 256 nodes, the storage space needed for handling images in legacy implementations can reach 256 customized images—far too large. For larger installations with 1024 or more processors, the storage demands needed for up to 1024 customized images becomes utterly unwieldy, easily outstripping the available storage scratch space of even large modern hard disk drives (HDDs) and solid state disks (SSDs). Moreover, some system administration use cases involve use of a small external node such as a laptop from which to perform configuring and/or reconfiguring the group of processors. Techniques are needed to support reimaging of even very large groups of processors without placing severe or impossible demands on the storage space needed on the external node. What is needed is a technique that generates processor-specific image configurations (e.g., ISO configurations), and that do not require huge areas for storage.
What is needed is a technique or techniques to improve over legacy approaches.